The mobile spectrum is a shared and scarce resource. This leads to congestion situations which penalizes end user traffic with higher latency. For some services this is not acceptable and there is even a willingness from e.g. service providers or enterprises to pay for prioritization of selected service traffic in order to avoid the negative effects of congestion.
In mobile communication networks it is known to direct network traffic related to a specific service to a bearer with a certain quality of service (QoS). In this respect, a bearer is considered to be an information transmission context or path of defined characteristics, e.g. capacity, delay and/or bit error rate. Typically, a number of bearers will be established between a gateway of a mobile communication network and a user equipment, e.g. a mobile phone or other type of mobile terminal. A bearer may carry downlink (DL) data traffic in a direction from the network to the user equipment, and may carry data traffic in an uplink (UL) direction from the user equipment to the network. In the gateway and in the user equipment the data traffic, which includes a plurality of IP data packets (IP: “Internet Protocol”) can be filtered using IP 5-tuple packet filters, thereby directing the IP data packets to a desired bearer.
Specifically, it is desired to direct data traffic relating to a specific service, e.g. mobile TV, to a bearer offering a certain QoS. For this purpose, DL data traffic may be subjected to a packet inspection so as to identify data packets relating to a specific service. When data packets of a predefined service are detected, this may be signaled to a policy controller. The policy controller may then generate corresponding packet filters and signal these packet filters to the gateway. The gateway then uses the received packet filters to route the data packets to a desired bearer. The bearer typically has a QoS class which was chosen by the network operator for the specific service. In this process, there may also be signaling to the user equipment, e.g. for establishing the bearer and indicating UL packet filters to the user equipment, which should be used to route UL data traffic onto the bearer.
Thus, to achieve this prioritization, packet inspection technologies are employed, either shallow/header inspection and/or deep packet inspection, This is a perfectly reasonable approach as long as it is possible to perform the necessary packet inspection.
However, when traffic is VPN encapsulated (e.g. using IPSec or SSL), as enterprise traffic often is, this packet inspection is not possible, as the service related data is hidden with the encapsulated, often encrypted packet. This is illustrated by FIG. 1, showing that the VPN traffic can be transported on one bearer since the VPN packets are encapsulated in a way making the packet inspection impossible.
In. FIG. 1 a client 10 which could also be an application or a web page 10 would like to exchange data with either a public web server 80 or an enterprise server 60. For VPN encapsulation a VPN client 20 is provided transmitting data to a VPN server 50 via a traffic detector mapper 30. A traffic detector/mapper 40 in the network domains is provided. At the VPN server side a firewall 70 is additionally provided. A tunnel is generated between the VPN client and the VPN server. Neither traffic mapper 30 nor traffic mapper 40 can inspect the encapsulated packets.
This is a type of problem that exists with all kind of QoS for tunneled traffic. Therefore many routers have features to deal with it (to a limited degree), Cisco for instance calls it pre-classification. With this approach the packet is inspected before encapsulation and the result is “remembered” such that e.g. QoS policies can be applied on the outgoing tunneled packet.
The problem however with such schemes is that they are very local (within a router) and e.g. don't work over organization boundaries. Also they are not specifically addressing client VPNs, but are typically applied where VPNs are used as part of a network setup (site-to-site).